무용 코드 제거

작성자

익명

작성일

2026.07.16

조회수

버전

무용 코드 제거 컴파일러 최적화 정적 분석 제어 흐름 그래프 데이터 흐름 분석 트리 쉐이킹 기술 부채 중급

📋 문서 버전

이 문서는 2개의 버전이 있습니다. 현재 최신 버전을 보고 있습니다.

무용 코드 제거 (Dead Code Elimination)

1. 개요

무용 코드 제거(Dead Code Elimination, DCE)란 프로그램의 실행 결과에 아무런 영향을 주지 않는 코드, 즉 실행될 가능성이 없거나 실행되더라도 그 결과가 이후 과정에서 사용되지 않는 코드를 찾아내어 삭제하는 컴파일러 최적화 기법이다.

DCE의 주된 목적은 프로그램의 논리적 동작을 유지하면서 자원 효율성을 극대화하는 것이다. 이를 통해 최종 생성되는 바이너리의 크기를 줄여 메모리 점유율을 낮추고, 불필요한 CPU 연산을 제거하여 실행 속도를 향상시킬 수 있다.

2. 무용 코드의 유형

무용 코드는 단순히 '사용하지 않는 코드'를 넘어, 분석 관점에 따라 다음과 같이 세분화된다.

유형	정의	특징	예시
도달 불가능한 코드 (Unreachable Code)	프로그램의 제어 흐름상 절대 실행될 수 없는 코드 영역	조건문이 항상 거짓이거나, `return` 문 이후에 위치한 코드	`if (false) { ... }` 내부 코드
사용되지 않는 코드 (Unused Code)	정의되었으나 이후 어느 곳에서도 참조되지 않는 변수, 함수, 클래스	메모리만 점유하고 실제 연산에는 기여하지 않음	선언만 하고 호출하지 않은 헬퍼 함수
데드 스토어 (Dead Store)	변수에 값을 할당했으나, 해당 값이 다시 읽히기 전에 다른 값으로 덮어씌워지거나 프로그램이 종료되는 경우	쓰기 연산은 발생하지만 읽기 연산이 없어 결과적으로 무의미함	`x = 10; x = 20;` 에서 `x = 10` 부분

3. 작동 원리 및 분석 기법

컴파일러는 정적 분석(Static Analysis)을 통해 코드를 실행하지 않고도 무용 여부를 판단한다. 이때 다음과 같은 핵심 기법들이 사용된다.

3.1 제어 흐름 그래프 (Control Flow Graph, CFG)

CFG는 프로그램의 모든 경로를 방향성 그래프로 표현한 것이다. 각 노드는 기본 블록(Basic Block)을 나타내며, 간선은 실행 흐름을 나타낸다. 컴파일러는 진입점(Entry Point)부터 시작하여 도달 가능한 모든 노드를 탐색하며, 어떤 경로로도 접근할 수 없는 노드를 '도달 불가능한 코드'로 판정한다.

3.2 데이터 흐름 분석 (Data-flow Analysis)

변수의 값이 프로그램 내에서 어떻게 전파되는지 추적하는 기법이다. 특정 지점에서 계산된 값이 이후의 연산에 영향을 주는지 분석하여, 결과값이 버려지는 연산 과정을 찾아낸다.

3.3 라이브 변수 분석 (Live Variable Analysis)

특정 프로그램 지점에서 변수가 라이브(Live) 상태인지 확인하는 분석이다. 변수가 라이브하다는 것은 해당 변수의 현재 값이 향후 실행될 코드에서 최소 한 번 이상 읽힐 가능성이 있다는 것을 의미한다.

이 분석은 코드의 끝에서부터 시작하여 위로 올라가는 역방향 분석(Backward Analysis) 방식으로 수행된다. 미래의 사용 여부를 확인하여 현재의 할당이 유효한지를 판단하기 때문이다. 만약 변수가 더 이상 라이브하지 않다면, 해당 변수에 값을 할당하는 코드는 데드 스토어로 간주되어 제거된다.

4. 구현 단계 및 최적화 과정

DCE는 단독으로 수행되기보다 다른 최적화 기법과 상호작용하며 반복적으로 적용될 때 효과가 극대화된다.

4.1 최적화 상호작용

상수 폴딩(Constant Folding): 컴파일 타임에 상수 연산을 미리 계산한다. $\rightarrow$ 이 과정에서 조건문이 if (true) 등으로 확정되면, 반대 경로가 도달 불가능한 코드가 되어 DCE의 대상이 된다.
인라이닝(Inlining): 함수 호출 부분을 함수의 본문으로 대체한다. $\rightarrow$ 함수 내부의 일부 인자가 사용되지 않음이 드러나면 해당 연산이 DCE로 제거된다.

4.2 코드 예시 (Before & After)

[최적화 전]

int calculate(int a) {
    int b = a * 2;       // (1) Dead Store: b에 값을 할당했으나 이후 읽히지 않음
    int c = 10;          // (2) Dead Store: c에 값을 할당했으나 이후 읽히지 않음
    if (0) {             // (3) Unreachable Code: 조건이 항상 거짓
        return c + 100;  // (4) Unreachable Code: 실행될 가능성 없음
    }
    int result = a + 5;
    return result;
}

[최적화 후]

int calculate(int a) {
    // b, c 할당문(Dead Store) 및 if문 전체(Unreachable Code)가 제거됨
    return a + 5;
}

5. 주의사항 및 한계

DCE는 강력하지만, 컴파일러가 코드의 '의도'를 완벽히 파악하지 못할 때 위험 요소가 존재한다.

5.1 사이드 이펙트 (Side Effect)

함수가 값을 반환하지 않더라도, 전역 변수를 수정하거나 I/O 작업을 수행하는 경우 이를 '무용 코드'로 오판하여 삭제하면 프로그램의 동작이 바뀐다.

[사이드 이펙트 발생 사례]

int global_val = 0;
int side_effect_func() {
    global_val++; // 전역 상태를 변경하는 사이드 이펙트 발생
    return 1;
}

int main() {
    int x = side_effect_func(); // x의 결과값을 사용하지 않음
    // x는 이후에 전혀 참조되지 않음
    return 0;
}

위 코드에서 컴파일러가 x가 사용되지 않는다는 이유로 side_effect_func() 호출 자체를 제거한다면, global_val이 증가하지 않고 0으로 남는 치명적인 논리 오류가 발생한다. 따라서 컴파일러는 함수가 pure(부작용 없음)한지 엄격히 검사해야 한다.

또한, C/C++ 등에서는 하드웨어 레지스터 접근이나 멀티스레드 환경에서 컴파일러의 무분별한 DCE를 막기 위해 <a href="/doc/%EA%B8%B0%EC%88%A0/%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D/C%2B%2B/volatile" class="wiki-link wiki-link-missing">volatile</a> 키워드를 사용한다. 이를 통해 해당 변수에 대한 접근이 무용해 보이더라도 최적화 과정에서 삭제되지 않도록 강제할 수 있다.

5.2 기타 한계

외부 라이브러리 의존성: 리플렉션(Reflection)이나 동적 로딩을 사용하는 언어에서는 런타임에 코드가 호출될 수 있어 정적 분석만으로는 제거 여부를 결정하기 어렵다.
디버깅 어려움: 최적화 후의 바이너리는 원본 소스 코드와 구조가 완전히 다르므로, 디버거에서 소스 라인과 실행 지점이 일치하지 않는 현상이 발생한다. 예를 들어, 소스 코드상에는 존재하는 변수가 최적화 후 바이너리에서는 완전히 사라져 '값이 최적화되어 표시할 수 없음(value optimized out)'이라는 메시지가 출력될 수 있다.

6. 관련 도구 및 언어별 적용

6.1 유사 최적화 기법 비교

기법	목적	DCE와의 차이점
상수 폴딩 (Constant Folding)	런타임 연산 감소	값을 미리 계산하는 것이며, 이 결과로 DCE가 유도됨
루프 언롤링 (Loop Unrolling)	분기 오버헤드 감소	루프 횟수를 늘려 성능을 높이는 기법 (코드 크기 증가 가능성)
인라이닝 (Inlining)	함수 호출 오버헤드 제거	함수 본문을 삽입하는 것이며, 이후 DCE를 통해 불필요한 인자 제거

6.2 언어 및 컴파일러별 구현

LLVM / GCC: -O1, -O2, -O3 옵션을 통해 단계별 최적화를 수행한다. 특히 -Os 옵션은 바이너리 크기 최소화에 집중하여 DCE를 적극적으로 활용한다. LLVM의 경우 중간 표현(IR) 단계에서 instcombine 및 adce(Aggressive DCE) 패스를 통해 매우 정교하게 무용 코드를 제거한다.
JavaScript (Webpack/Rollup): 트리 쉐이킹(Tree Shaking)이라는 이름으로 구현된다. ES 모듈(import/export)의 정적 구조를 분석하여 사용되지 않는 모듈 전체를 번들링 결과물에서 제외한다.
Java (ProGuard/R8): 안드로이드 개발에서 주로 사용되며, 사용되지 않는 클래스, 필드, 메서드를 제거하고 이름을 축약(Obfuscation)하여 APK 크기를 줄인다.

6.3 컴파일러 최적화 설정법 (GCC/Clang 기준)

터미널에서 컴파일 시 다음과 같은 플래그를 사용하여 DCE를 포함한 최적화를 활성화할 수 있다.

# 기본 최적화 (DCE 포함 기초 최적화 적용)
gcc -O1 main.c -o main

# 권장 최적화 (대부분의 DCE 및 데이터 흐름 분석 적용, 실행 속도 향상)
gcc -O2 main.c -o main

# 크기 최적화 (바이너리 크기 감소를 위해 DCE 및 공격적인 제거 적용)
gcc -Os main.c -o main

구형 코드의 정의와 특성

무용 코드의 범주에는 컴파일러가 탐지하는 물리적 무용 코드 외에, 비즈니스 관점의 구형 코드(Legacy/Obsolete Code)가 포함된다.

구형 코드는 제어 흐름상으로는 도달 가능(Reachable)하여 컴파일러가 자동으로 제거할 수 없으나, 비즈니스 요구사항의 변경이나 시스템 아키텍처의 진화로 인해 더 이상 논리적인 가치를 제공하지 않는 코드를 의미한다. 이러한 코드는 실제 실행되더라도 결과가 무시되거나, 과거의 특정 예외 케이스를 처리하기 위해 존재하지만 현재는 해당 케이스가 발생하지 않는 경우가 많다. 구형 코드를 방치할 경우 코드 가독성을 저해하고, 새로운 기능을 추가할 때 불필요한 영향도 분석 비용을 증가시키는 원인이 된다.

숨은 의존성 및 제거 위험성

구형 코드를 수동으로 제거할 때는 정적 분석 도구가 잡아내지 못하는 숨은 의존성(Hidden Dependency) 문제를 주의해야 한다.

숨은 의존성의 위험 요소

동적 호출 및 리플렉션: 문자열 기반의 클래스/메서드 호출이나 설정 파일에 정의된 클래스 경로를 통해 런타임에 호출되는 코드는 정적 분석에서 '사용되지 않음'으로 표시되지만, 삭제 시 런타임 에러(ClassNotFoundException 등)를 유발한다.
암묵적 예외 처리: 과거의 특정 버그나 외부 시스템의 불안정성을 해결하기 위해 추가된 '방어적 코드'의 경우, 문서화되지 않은 경우가 많다. 이를 무용 코드로 판단해 삭제하면, 드물게 발생하는 엣지 케이스에서 시스템이 붕괴될 위험이 있다.

안전한 제거를 위한 체크리스트

코드를 삭제하기 전, 다음 항목을 검토하여 사이드 이펙트를 최소화해야 한다. - [ ] 런타임 호출 확인: 리플렉션, 의존성 주입(DI) 프레임워크, 동적 프록시를 통해 호출되는 지점이 없는가? - [ ] 외부 인터페이스 검토: API 엔드포인트, 메시지 큐 리스너 등 외부 시스템에서 호출하는 진입점인가? - [ ] 로그 및 모니터링 확인: 최근 3~6개월간 해당 코드 경로를 통과한 로그 기록이 존재하는가? - [ ] 테스트 커버리지 확인: 해당 코드를 검증하는 테스트 케이스가 존재하는가? 삭제 후 기존 테스트가 모두 통과하는가?

정적 분석 도구를 통한 탐지 및 권고

현대적인 IDE와 정적 분석 도구는 개발 단계에서 무용 코드를 시각적으로 표시하고 제거를 권고한다.

도구별 탐지 방식

IntelliJ IDEA: 사용되지 않는 변수, 메서드, 클래스를 회색(Greyed out)으로 표시하며, Inspect Code 기능을 통해 프로젝트 전체의 무용 코드를 리스트업한다.
SonarQube: 'Dead Code' 또는 'Unused Private Member'와 같은 코드 스멜(Code Smell) 규칙을 통해 이슈를 제기하며, 해당 코드가 유지보수성에 미치는 영향도를 수치화하여 제공한다.

설정 및 탐지 화면 예시

정적 분석 도구의 설정 화면에서는 제거 대상의 범위를 지정할 수 있다. (예: private 멤버만 탐지할 것인지, public API까지 포함할 것인지 설정)

![정적 분석 도구 설정 화면 캡처: SonarQube의 'Unused Code' 규칙 활성화 및 IntelliJ의 'Inspection' 설정 화면 예시] (참고: 실제 환경에서는 Settings $\rightarrow$ Editor $\rightarrow$ Inspections $\rightarrow$ Java $\rightarrow$ Declaration redundancy 경로에서 설정 가능)

최적화 관점의 점진적 제거 전략

대규모 시스템에서 구형 코드를 한 번에 삭제하는 것은 리스크가 크다. 따라서 다음과 같은 단계적 전략을 권장한다.

1단계: Deprecation 표시

삭제 전 @Deprecated 어노테이션이나 로그를 통해 해당 코드가 곧 제거될 예정임을 알린다. 이는 다른 개발자가 해당 코드를 새로 참조하는 것을 방지한다.

2단계: 기능 플래그(Feature Flag) 활용

코드의 실행 경로를 플래그로 제어하여, 실제 삭제 전 런타임에 안전하게 비활성화하고 문제가 없는지 확인한다.

[기능 플래그 활용 예시 코드]

public class OrderService {
    // 설정 파일이나 DB에서 관리되는 기능 플래그
    private final FeatureFlagManager featureFlags;

    public void processOrder(Order order) {
        // 신규 로직 적용
        processNewOrderLogic(order);

        // 구형 로직을 기능 플래그로 제어
        if (featureFlags.isEnabled("use-legacy-order-logic")) {
            // 점진적 제거 대상: 플래그가 false가 되면 실행되지 않음
            processLegacyOrderLogic(order); 
        }
    }
}

3단계: 완전 제거 및 리팩토링

플래그를 통해 구형 코드의 영향력이 없음이 검증되면, 해당 코드와 플래그 제어문을 완전히 삭제하여 코드베이스를 정돈한다.

구형 코드 처리와 기술 부채 관리

무용 코드 제거는 단순한 최적화를 넘어 기술 부채(Technical Debt)를 상환하는 과정이다.

레거시 식별 및 제거 전략

코드 마이닝(Code Mining): Git 커밋 히스토리를 분석하여 오랫동안 수정되지 않았거나, 특정 기능 삭제 후 남겨진 '잔재 코드'를 식별한다.
가시화: 무용 코드의 양을 측정하여 기술 부채 지표로 관리하고, 스프린트마다 일정 비율의 무용 코드를 제거하는 'Clean-up Day'를 운영한다.

기술 부채 감소의 상관관계

무용 코드가 감소하면 다음과 같은 선순환 구조가 형성된다. - 인지 부하 감소: 개발자가 분석해야 할 코드 양이 줄어들어 비즈니스 로직 파악 속도가 빨라진다. - 빌드 및 배포 속도 향상: 컴파일 대상 파일과 바이너리 크기가 줄어들어 CI/CD 파이프라인의 효율이 증가한다. - 버그 발생률 저하: 사용하지 않는 코드에서 발생하는 잠재적 버그나, 잘못된 구형 로직을 참조하여 발생하는 논리 오류를 원천 차단한다.

📝 마크다운 원본

이 문서의 마크다운 원본 내용입니다.

# 무용 코드 제거 (Dead Code Elimination)

## 1. 개요
**무용 코드 제거(Dead Code Elimination, DCE)**란 프로그램의 실행 결과에 아무런 영향을 주지 않는 코드, 즉 실행될 가능성이 없거나 실행되더라도 그 결과가 이후 과정에서 사용되지 않는 코드를 찾아내어 삭제하는 컴파일러 최적화 기법이다.

DCE의 주된 목적은 프로그램의 논리적 동작을 유지하면서 자원 효율성을 극대화하는 것이다. 이를 통해 최종 생성되는 바이너리의 크기를 줄여 메모리 점유율을 낮추고, 불필요한 CPU 연산을 제거하여 실행 속도를 향상시킬 수 있다.

## 2. 무용 코드의 유형
무용 코드는 단순히 '사용하지 않는 코드'를 넘어, 분석 관점에 따라 다음과 같이 세분화된다.

| 유형 | 정의 | 특징 | 예시 |
| :--- | :--- | :--- | :--- |
| **도달 불가능한 코드 (Unreachable Code)** | 프로그램의 제어 흐름상 절대 실행될 수 없는 코드 영역 | 조건문이 항상 거짓이거나, `return` 문 이후에 위치한 코드 | `if (false) { ... }` 내부 코드 |
| **사용되지 않는 코드 (Unused Code)** | 정의되었으나 이후 어느 곳에서도 참조되지 않는 변수, 함수, 클래스 | 메모리만 점유하고 실제 연산에는 기여하지 않음 | 선언만 하고 호출하지 않은 헬퍼 함수 |
| **데드 스토어 (Dead Store)** | 변수에 값을 할당했으나, 해당 값이 다시 읽히기 전에 다른 값으로 덮어씌워지거나 프로그램이 종료되는 경우 | 쓰기 연산은 발생하지만 읽기 연산이 없어 결과적으로 무의미함 | `x = 10; x = 20;` 에서 `x = 10` 부분 |

## 3. 작동 원리 및 분석 기법
컴파일러는 정적 분석(Static Analysis)을 통해 코드를 실행하지 않고도 무용 여부를 판단한다. 이때 다음과 같은 핵심 기법들이 사용된다.

### 3.1 제어 흐름 그래프 (Control Flow Graph, CFG)
CFG는 프로그램의 모든 경로를 방향성 그래프로 표현한 것이다. 각 노드는 기본 블록(Basic Block)을 나타내며, 간선은 실행 흐름을 나타낸다. 컴파일러는 진입점(Entry Point)부터 시작하여 도달 가능한 모든 노드를 탐색하며, 어떤 경로로도 접근할 수 없는 노드를 '도달 불가능한 코드'로 판정한다.

### 3.2 데이터 흐름 분석 (Data-flow Analysis)
변수의 값이 프로그램 내에서 어떻게 전파되는지 추적하는 기법이다. 특정 지점에서 계산된 값이 이후의 연산에 영향을 주는지 분석하여, 결과값이 버려지는 연산 과정을 찾아낸다.

### 3.3 라이브 변수 분석 (Live Variable Analysis)
특정 프로그램 지점에서 변수가 **라이브(Live)** 상태인지 확인하는 분석이다. 변수가 라이브하다는 것은 해당 변수의 현재 값이 향후 실행될 코드에서 최소 한 번 이상 읽힐 가능성이 있다는 것을 의미한다. 

이 분석은 코드의 끝에서부터 시작하여 위로 올라가는 **역방향 분석(Backward Analysis)** 방식으로 수행된다. 미래의 사용 여부를 확인하여 현재의 할당이 유효한지를 판단하기 때문이다. 만약 변수가 더 이상 라이브하지 않다면, 해당 변수에 값을 할당하는 코드는 데드 스토어로 간주되어 제거된다.

## 4. 구현 단계 및 최적화 과정
DCE는 단독으로 수행되기보다 다른 최적화 기법과 상호작용하며 반복적으로 적용될 때 효과가 극대화된다.

### 4.1 최적화 상호작용
1. **상수 폴딩(Constant Folding):** 컴파일 타임에 상수 연산을 미리 계산한다. $\rightarrow$ 이 과정에서 조건문이 `if (true)` 등으로 확정되면, 반대 경로가 도달 불가능한 코드가 되어 DCE의 대상이 된다.
2. **인라이닝(Inlining):** 함수 호출 부분을 함수의 본문으로 대체한다. $\rightarrow$ 함수 내부의 일부 인자가 사용되지 않음이 드러나면 해당 연산이 DCE로 제거된다.

### 4.2 코드 예시 (Before & After)

**[최적화 전]**
```c
int calculate(int a) {
    int b = a * 2;       // (1) Dead Store: b에 값을 할당했으나 이후 읽히지 않음
    int c = 10;          // (2) Dead Store: c에 값을 할당했으나 이후 읽히지 않음
    if (0) {             // (3) Unreachable Code: 조건이 항상 거짓
        return c + 100;  // (4) Unreachable Code: 실행될 가능성 없음
    }
    int result = a + 5;
    return result;
}
```

**[최적화 후]**
```c
int calculate(int a) {
    // b, c 할당문(Dead Store) 및 if문 전체(Unreachable Code)가 제거됨
    return a + 5;
}
```

## 5. 주의사항 및 한계
DCE는 강력하지만, 컴파일러가 코드의 '의도'를 완벽히 파악하지 못할 때 위험 요소가 존재한다.

### 5.1 사이드 이펙트 (Side Effect)
함수가 값을 반환하지 않더라도, 전역 변수를 수정하거나 I/O 작업을 수행하는 경우 이를 '무용 코드'로 오판하여 삭제하면 프로그램의 동작이 바뀐다.

**[사이드 이펙트 발생 사례]**
```cpp
int global_val = 0;
int side_effect_func() {
    global_val++; // 전역 상태를 변경하는 사이드 이펙트 발생
    return 1;
}

int main() {
    int x = side_effect_func(); // x의 결과값을 사용하지 않음
    // x는 이후에 전혀 참조되지 않음
    return 0;
}
```
위 코드에서 컴파일러가 `x`가 사용되지 않는다는 이유로 `side_effect_func()` 호출 자체를 제거한다면, `global_val`이 증가하지 않고 0으로 남는 치명적인 논리 오류가 발생한다. 따라서 컴파일러는 함수가 `pure`(부작용 없음)한지 엄격히 검사해야 한다.

또한, C/C++ 등에서는 하드웨어 레지스터 접근이나 멀티스레드 환경에서 컴파일러의 무분별한 DCE를 막기 위해 `volatile` 키워드를 사용한다. 이를 통해 해당 변수에 대한 접근이 무용해 보이더라도 최적화 과정에서 삭제되지 않도록 강제할 수 있다.

### 5.2 기타 한계
- **외부 라이브러리 의존성:** 리플렉션(Reflection)이나 동적 로딩을 사용하는 언어에서는 런타임에 코드가 호출될 수 있어 정적 분석만으로는 제거 여부를 결정하기 어렵다.
- **디버깅 어려움:** 최적화 후의 바이너리는 원본 소스 코드와 구조가 완전히 다르므로, 디버거에서 소스 라인과 실행 지점이 일치하지 않는 현상이 발생한다. 예를 들어, 소스 코드상에는 존재하는 변수가 최적화 후 바이너리에서는 완전히 사라져 '값이 최적화되어 표시할 수 없음(value optimized out)'이라는 메시지가 출력될 수 있다.

## 6. 관련 도구 및 언어별 적용

### 6.1 유사 최적화 기법 비교
| 기법 | 목적 | DCE와의 차이점 |
| :--- | :--- | :--- |
| **상수 폴딩 (Constant Folding)** | 런타임 연산 감소 | 값을 미리 계산하는 것이며, 이 결과로 DCE가 유도됨 |
| **루프 언롤링 (Loop Unrolling)** | 분기 오버헤드 감소 | 루프 횟수를 늘려 성능을 높이는 기법 (코드 크기 증가 가능성) |
| **인라이닝 (Inlining)** | 함수 호출 오버헤드 제거 | 함수 본문을 삽입하는 것이며, 이후 DCE를 통해 불필요한 인자 제거 |

### 6.2 언어 및 컴파일러별 구현
- **LLVM / GCC:** `-O1`, `-O2`, `-O3` 옵션을 통해 단계별 최적화를 수행한다. 특히 `-Os` 옵션은 바이너리 크기 최소화에 집중하여 DCE를 적극적으로 활용한다. LLVM의 경우 중간 표현(IR) 단계에서 `instcombine` 및 `adce`(Aggressive DCE) 패스를 통해 매우 정교하게 무용 코드를 제거한다.
- **JavaScript (Webpack/Rollup):** **트리 쉐이킹(Tree Shaking)**이라는 이름으로 구현된다. ES 모듈(`import`/`export`)의 정적 구조를 분석하여 사용되지 않는 모듈 전체를 번들링 결과물에서 제외한다.
- **Java (ProGuard/R8):** 안드로이드 개발에서 주로 사용되며, 사용되지 않는 클래스, 필드, 메서드를 제거하고 이름을 축약(Obfuscation)하여 APK 크기를 줄인다.

### 6.3 컴파일러 최적화 설정법 (GCC/Clang 기준)
터미널에서 컴파일 시 다음과 같은 플래그를 사용하여 DCE를 포함한 최적화를 활성화할 수 있다.

```bash
# 기본 최적화 (DCE 포함 기초 최적화 적용)
gcc -O1 main.c -o main

# 권장 최적화 (대부분의 DCE 및 데이터 흐름 분석 적용, 실행 속도 향상)
gcc -O2 main.c -o main

# 크기 최적화 (바이너리 크기 감소를 위해 DCE 및 공격적인 제거 적용)
gcc -Os main.c -o main
```

## 구형 코드의 정의와 특성
무용 코드의 범주에는 컴파일러가 탐지하는 물리적 무용 코드 외에, 비즈니스 관점의 **구형 코드(Legacy/Obsolete Code)**가 포함된다.

구형 코드는 제어 흐름상으로는 도달 가능(Reachable)하여 컴파일러가 자동으로 제거할 수 없으나, 비즈니스 요구사항의 변경이나 시스템 아키텍처의 진화로 인해 더 이상 논리적인 가치를 제공하지 않는 코드를 의미한다. 이러한 코드는 실제 실행되더라도 결과가 무시되거나, 과거의 특정 예외 케이스를 처리하기 위해 존재하지만 현재는 해당 케이스가 발생하지 않는 경우가 많다. 구형 코드를 방치할 경우 코드 가독성을 저해하고, 새로운 기능을 추가할 때 불필요한 영향도 분석 비용을 증가시키는 원인이 된다.

## 숨은 의존성 및 제거 위험성
구형 코드를 수동으로 제거할 때는 정적 분석 도구가 잡아내지 못하는 **숨은 의존성(Hidden Dependency)** 문제를 주의해야 한다.

### 숨은 의존성의 위험 요소
- **동적 호출 및 리플렉션:** 문자열 기반의 클래스/메서드 호출이나 설정 파일에 정의된 클래스 경로를 통해 런타임에 호출되는 코드는 정적 분석에서 '사용되지 않음'으로 표시되지만, 삭제 시 런타임 에러(`ClassNotFoundException` 등)를 유발한다.
- **암묵적 예외 처리:** 과거의 특정 버그나 외부 시스템의 불안정성을 해결하기 위해 추가된 '방어적 코드'의 경우, 문서화되지 않은 경우가 많다. 이를 무용 코드로 판단해 삭제하면, 드물게 발생하는 엣지 케이스에서 시스템이 붕괴될 위험이 있다.

### 안전한 제거를 위한 체크리스트
코드를 삭제하기 전, 다음 항목을 검토하여 사이드 이펙트를 최소화해야 한다.
- [ ] **런타임 호출 확인:** 리플렉션, 의존성 주입(DI) 프레임워크, 동적 프록시를 통해 호출되는 지점이 없는가?
- [ ] **외부 인터페이스 검토:** API 엔드포인트, 메시지 큐 리스너 등 외부 시스템에서 호출하는 진입점인가?
- [ ] **로그 및 모니터링 확인:** 최근 3~6개월간 해당 코드 경로를 통과한 로그 기록이 존재하는가?
- [ ] **테스트 커버리지 확인:** 해당 코드를 검증하는 테스트 케이스가 존재하는가? 삭제 후 기존 테스트가 모두 통과하는가?

## 정적 분석 도구를 통한 탐지 및 권고
현대적인 IDE와 정적 분석 도구는 개발 단계에서 무용 코드를 시각적으로 표시하고 제거를 권고한다.

### 도구별 탐지 방식
- **IntelliJ IDEA:** 사용되지 않는 변수, 메서드, 클래스를 회색(Greyed out)으로 표시하며, `Inspect Code` 기능을 통해 프로젝트 전체의 무용 코드를 리스트업한다.
- **SonarQube:** 'Dead Code' 또는 'Unused Private Member'와 같은 코드 스멜(Code Smell) 규칙을 통해 이슈를 제기하며, 해당 코드가 유지보수성에 미치는 영향도를 수치화하여 제공한다.

### 설정 및 탐지 화면 예시
정적 분석 도구의 설정 화면에서는 제거 대상의 범위를 지정할 수 있다. (예: `private` 멤버만 탐지할 것인지, `public` API까지 포함할 것인지 설정)

![정적 분석 도구 설정 화면 캡처: SonarQube의 'Unused Code' 규칙 활성화 및 IntelliJ의 'Inspection' 설정 화면 예시]
*(참고: 실제 환경에서는 `Settings` $\rightarrow$ `Editor` $\rightarrow$ `Inspections` $\rightarrow$ `Java` $\rightarrow$ `Declaration redundancy` 경로에서 설정 가능)*

## 최적화 관점의 점진적 제거 전략
대규모 시스템에서 구형 코드를 한 번에 삭제하는 것은 리스크가 크다. 따라서 다음과 같은 단계적 전략을 권장한다.

### 1단계: Deprecation 표시
삭제 전 `@Deprecated` 어노테이션이나 로그를 통해 해당 코드가 곧 제거될 예정임을 알린다. 이는 다른 개발자가 해당 코드를 새로 참조하는 것을 방지한다.

### 2단계: 기능 플래그(Feature Flag) 활용
코드의 실행 경로를 플래그로 제어하여, 실제 삭제 전 런타임에 안전하게 비활성화하고 문제가 없는지 확인한다.

**[기능 플래그 활용 예시 코드]**
```java
public class OrderService {
    // 설정 파일이나 DB에서 관리되는 기능 플래그
    private final FeatureFlagManager featureFlags;

    public void processOrder(Order order) {
        // 신규 로직 적용
        processNewOrderLogic(order);

        // 구형 로직을 기능 플래그로 제어
        if (featureFlags.isEnabled("use-legacy-order-logic")) {
            // 점진적 제거 대상: 플래그가 false가 되면 실행되지 않음
            processLegacyOrderLogic(order); 
        }
    }
}
```

### 3단계: 완전 제거 및 리팩토링
플래그를 통해 구형 코드의 영향력이 없음이 검증되면, 해당 코드와 플래그 제어문을 완전히 삭제하여 코드베이스를 정돈한다.

## 구형 코드 처리와 기술 부채 관리
무용 코드 제거는 단순한 최적화를 넘어 **기술 부채(Technical Debt)**를 상환하는 과정이다.

### 레거시 식별 및 제거 전략
1. **코드 마이닝(Code Mining):** Git 커밋 히스토리를 분석하여 오랫동안 수정되지 않았거나, 특정 기능 삭제 후 남겨진 '잔재 코드'를 식별한다.
2. **가시화:** 무용 코드의 양을 측정하여 기술 부채 지표로 관리하고, 스프린트마다 일정 비율의 무용 코드를 제거하는 'Clean-up Day'를 운영한다.

### 기술 부채 감소의 상관관계
무용 코드가 감소하면 다음과 같은 선순환 구조가 형성된다.
- **인지 부하 감소:** 개발자가 분석해야 할 코드 양이 줄어들어 비즈니스 로직 파악 속도가 빨라진다.
- **빌드 및 배포 속도 향상:** 컴파일 대상 파일과 바이너리 크기가 줄어들어 CI/CD 파이프라인의 효율이 증가한다.
- **버그 발생률 저하:** 사용하지 않는 코드에서 발생하는 잠재적 버그나, 잘못된 구형 로직을 참조하여 발생하는 논리 오류를 원천 차단한다.

AI 생성 콘텐츠 안내

이 문서는 AI 모델(gemma-4-31b)에 의해 생성된 콘텐츠입니다.

주의사항: AI가 생성한 내용은 부정확하거나 편향된 정보를 포함할 수 있습니다. 중요한 결정을 내리기 전에 반드시 신뢰할 수 있는 출처를 통해 정보를 확인하시기 바랍니다.

위키너와나